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SYSTEM AND METHOD FOR ELECTRONIC TRANSMISSION, 
STORAGE AND RETRIEVAL OF AUTHENTICATED DOCUMENTS 

This application is a continuation-in-part of U.S. Patent Application 
No. 09/737,325 filed on December 14, 2000, which is a continuation of International 
Application No. PCT/US00/32746, filed on December 1, 2000, that designates the 
United States, and a continuation-in-part of U.S. Patent Application No. 09/452,928, 
filed on December 2, 1999, now U.S. Patent No. 6,367,013, which is a continuation-in- 
part of U.S. Patent Application No. 09/072,079 filed on May 4, 1998, now U.S. Patent 
No. 6,237,096, which is a continuation-in-part of U.S. Patent Application 
No. 08/528,841 filed September 15, 1995, now U.S. Patent No. 5,748,738, which is a 
continuation-in-part of U.S. Patent Application No. 08/373,944 filed January 17, 1995, 
now U.S. Patent No. 5,615,268, all by Bisbee et al. This application claims priority to 
the filing date of U.S. Provisional Patent Application No. 60/397,178 that was filed on 
July 18, 2002. These patents and applications are incorporated in this application by 
reference. 

BACKGROUND 

Applicants' invention relates to systems and methods for providing a verifiable 
chain of evidence and security for the creation, execution, maintenance, transfer, 
retrieval and destruction of electronic original information objects, such as Electronic 
Original™ documents. 

This invention advantageously uses Applicants' Trusted Custodial Utility that 
holds electronic original records and comparable system roles as a virtual electronic 
vault in validating the right of an individual to perform a requisite action, the authenticity 
of submitted electronic information objects, and the status of the authentication 
certificates used in the digital signature verification and user authentication processes. 
Such TCUs and operations are described in U.S. Patents No. 5,615,268; No. 
5,748,738; No. 6,237,096; and No. 6,367,013. 

The following list of abbreviations is used in this description: 
Abbreviations 

CA Certification Authority 

CRL Certificate Revocation List 

CSS Certificate Status Service 
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HTML 
ID 

IETF 
ITU 
LDAP 
OCSP 



Hypertext Markup Language 
Identification 

Internet Engineering Task Force 
International Telecommunications Union 
Lightweight Directory Access Protocol 

Online Certificate Status Protocol, IETF-RFC 2560 X.509 Internet Public 
Key Infrastructure Online Certificate Status Protocol - OCSP, June 1999. 
Personal Identification Number 
Public-Key Cryptographic Standards 
Public Key Infrastructure 
Public Key Infrastructure (X.509) 
Secure Multi-Purpose Internet Mail Extensions 

Simple Certificate Validation Protocol, Draft-IETF-PKIX-SCVP-06, July 
2000 

Secure Socket Layer 
Trusted Custodial Utility 
Uniform Electronic Transactions Act 
Extensible Markup Language 
The U.S. Electronic Signatures in Global and National Commerce Act (ESIGN) 
legislation and U.S. state laws modeled after the UETA drafted by the National 
Conference of Commissioners on Uniform State Laws and approved and 
recommended for enactment in 1999 provide assurances of legal standing for 
electronically signed information objects (electronic documents) which has generated 
government, banking and electronic commerce activity aimed at realizing the efficiency 
and economies of these potentially wholly electronic transactions. 

PKI and the CA are the base elements of digital signature technology used in 
creating electronic source records. A PKI is a collection of CAs where trust is 
established between users and user organizations by creating either a hierarchical 
relationship between CAs or through cross-certification amongst cooperating CAs. A 
CA is empowered to issue authentication certificates that bind an individual's or entity's 
identity to his or its public key (verifying), where only the individual is given access to 
the matching private key (signing). At the time of this application, certificates normally 
conform to the ITU X.509 certificate standard and are themselves digitally signed by the 



PIN 

PKCS 

PKI 

PKIX 

S/MIME 

SCVP 

SSL 
TCU 
UETA 
XML 
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issuing CA. Such certificates are depicted in FIG. 10 of U.S. Patent No. 6,237,096, for 
example, that is cited and incorporated above. These authentication certificates 
contain a serial number, identifying information of the subject (user) and issuer (CA), 
the certificate's validity period (date and time before and after which it may not be 
5 used), the subject's public key, and cryptographic algorithm information needed to 
create and verify digital signatures. 

To create a digital signature, an information object is hashed (processed using a 
one-way cryptographic function that can detect as little as a one bit alteration in the 
object) and the hash is then encrypted using the individual's private (secret) key. Digital 
10 signature verification is achieved by reversing this process. The digital signature is 

decrypted using the individual's public key retrieved from their authentication certificate 
and the result is compared to a re-hash of the original information object. These 
processes may vary when using different digital signature algorithms. Digital signatures 
are only as reliable as the trust that exists between the relying parties and the issuing 
1 5 CAs; and the level of assurance achieved by the physical controls, practices and 
procedures implemented by the CAs. 

The purpose of PKI technology is to create and maintain both a secure and 
trusted environment for communicating parties. Such parties rely on the PKI to 
establish the identity of users and to notify them when a user's certificate is no longer 
20 viable. Certificates are revoked when an individual leaves an organization, when a 

replacement certificate is issued, or when a signing key is lost, stolen or compromised. 
Vendors report certificate status using a wide variety of methods. These diverse 
methods make it more difficult for users to obtain certificate status for other users. 
The formation of a trust relationship and interoperability is dictated by PKI 
25 certificate and security policies and their enforcement. The certificate policy determines 
the level of personal vetting (i.e., the process for validating appropriateness of 
certificate request information and the identity of the intended certificate recipient) 
required (e.g., two forms of picture ID, credit check) to gain approval for issuance of a 
certificate. The security policy dictates the physical, procedural and process controls 
30 needed to support the application environment. 

There are two prevalent models for creating and organizing CAs. The first is a 
hierarchical CA model that resembles an inverted tree whose top is the root CA. The 
root CA signs its immediate subordinate CAs' certificates. These CAs then sign their 
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subordinate CAs' certificates, and so on. These relationships create certificate chains 
that form branches of the tree. Two CAs prove that a trust relationship exists between 
them by "walking" their respective certificate chains until a common node is reached. 
CAs may be grouped and associated with one or more service delivery channels, 
5 industry verticals, organizations or enterprises. 

In the second model, a CA is created for a single enterprise and provides CA 
services to one or more entities within that enterprise. An enterprise CA does not 
normally have any pre-established trust relationships with any CA of another enterprise. 
Explicit action must be taken to allow interoperability in the form of CA cross- 
1 0 certification, whereby two or more CAs that agree to trust one another sign each other's 
certificate and use these cross-certified certificates during digital signature verification. 
Certificates issued by one CA can then be validated by the other cross-certified CA and 
its users. 

CAs revoke certificates when, among other reasons, the information contained 
15 therein becomes invalid, when the user's private key becomes compromised, or when it 
is necessary to terminate a user's certificate-based application privileges. CAs cannot 
simply delete or retrieve a certificate from its owner if it is already in the owner's 
possession. Instead, the certificate is marked as "revoked" in the CA's database and 
the certificate status is published. Users of the PKI can then learn of a certificate's 
20 validity by requesting certificate status from the issuing CA or identified status repository 
(directory). 

An early method used to report certificate status was by way of publication of a 
list of a CA's revoked certificates, known as a CRL. CRLs are downloaded by 
applications and relying parties to determine whether a particular user's certificate has 

25 been revoked and by extension whether that user's digital signature is still valid or not. 
With time, CRLs get longer, incurring both communication and data processing 
overhead. An additional shortcoming of this approach is that CRLs are often published 
at infrequent intervals (e.g., once or twice a day). For this reason, CRLs are often 
immediately out-of-date after publication. Revoked certificates are only removed from 

30 CRLs after certificate expiration. 

A PKI bridge is a method of providing interoperability between CAs by 
coordinating distribution of CRLs. Such a bridge is a central CRL repository that in 
effect joins a set of CAs that agree to accept each other's certificates and security 

4 



Attorney's Docket No. 003b/U-'iU4 
' ■ Patent 

policies. All CAs post their CRLs to the bridge. This allows for centralized validation of 
any individual's or entity's certificate. If the certificate has not been previously revoked, 
then it is still considered valid. The biggest disadvantage to PKI bridges is that they 
must be reachable by any CA or user relying on the bridge for certificate status. The 
5 bandwidth, computation, and storage requirements may be costly. 

A more recent method for obtaining certificate status is the IETF OCSP, which 
makes a direct database query that can provide real-time certificate status. However, 
some vendors have implemented OCSP responders that are based on CRLs. 
Certificate status reported by this type of responder is only as timely as the CRLs on 

10 which they are based. Attempts to achieve real-time certificate status, such as the IETF 
SCVP continue to be developed. At the time of this invention, mixing and matching of 
status checking methods has not been practical in an open PKI environment. 

Any approach to certificate validation is an all-or-nothing decision for the CA that 
issued the certificates. All users who are issued certificates by one of the member CAs 

1 5 are valid/enabled unless their certificate has been suspended or revoked or has 

expired. The common theme for controlling participation is whether a certificate gets 
issued. Issuance is governed by certificate and security policies and business rules. 

The trust environment can range from fully open, where anyone able to pay the 
price of admission is issued a certificate, to closed or bounded, by requiring 

20 membership in an enterprise or community of interest. In either case, CA certificate 
and/or security policies govern whether interoperability is allowed. 

Applicants' invention approaches the PKI and CA interoperability problem from a 
totally different point of view from those described above. Applicants' focus is on 
establishing a trust environment suitable for the creation, execution, maintenance, 

25 transfer, retrieval, and destruction of electronic original information objects that may 
also be transferable records (ownership may change hands). To realize these 
objectives, the system controlling an electronic original or authoritative copy must make 
it possible to identify the original from any copy thereof. As with paper originals, there 
can only be one original. Examples of transferable records are electronic negotiable 

30 instruments and securities. An electronic original record may be any source record, 
whether it qualifies as a transferable record or not. Transfer of electronic original 
records between systems must take place using methods that guarantee that only one 
original exists. 

5 
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This invention creates an electronic original record by placing custody of that 
record in the hands of a trusted independent party, functionary or TCU operated for the 
benefit of the record's owner. Creating a trust environment is necessary, but is not 
sufficient for maintaining electronic source records. For the purposes of this invention, 
5 a trust environment is created by formation of a community of interest that has a closed 
or bounded membership and where the identity of prospective members, organizations 
and their users is assured by using appropriate vetting procedures that govern the 
granting of admission to the community. Further, an individual's organization, 
participation, role, and attributes are defined at the time of enrollment with the TCU. 
10 Individuals must be uniquely identified to the system and in their authentication 

certificate. In addition, it must be possible to remove individuals and organizations from 
the community and to make this action known to other members of the community. 
Traditional approaches to CA interoperability do not adequately achieve these 
objectives. 

15 Vetting at a minimum requires that an organization and/or individual be 

sponsored by a known member of the community. In addition, a Dun and Bradstreet- 
like rating for organizations or an Equifax-like credit check for individuals, or an 
equivalent credit and payment history, may be utilized to evaluate acceptability of 
potential business partners, clients and customers. Both the vetting organization and 

20 its sponsored users must be deemed trustworthy before TCU enrollment is permitted. 
After an organization agrees to the contractual terms defining membership, its 
sponsored individuals will each be given a unique identifier and password that will 
enable them to access the TCU. 

Once an individual is enrolled with one or more TCUs, they can be named as a 

25 participant to a transaction by the owner of that transaction and given specific access to 
all or an identified subset of source records based on their identity, role, and/or 
responsibility. To facilitate identification and authentication and to enable the 
transactions to take place in a totally electronic form, a selected subset of this 
identifying information is included in the participant's authentication certificate. The 

30 authentication certificate binds the user's identity with their public-key used to validate 
digital signatures generated using their matching signing private-key. 

A certificate or security policy addresses the proof-of-identity requirements (e.g., 
two forms of picture ID, credit check, personal introduction) needed before issuing a 
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certificate. This certificate will be bound to the user's TCU account if required for digital 
signing authority. The linkage shall include a subset of certificate data elements that 
uniquely identify the user (e.g., certificate ID, issuing CA name, user common name). 
Once associated with a user's account, the certificate can be used in conjunction with 
5 his or its digital signature to afford the proof-of-identity needed to enable a 

predetermined set of authorized actions and to verify the user's digital signature on 
submitted information objects. This is especially true when the owner or owner's agent 
controlling a set of electronic records instructs the TCU to transfer ownership (i.e., an 
internal transaction) and/or to transfer custody (i.e., an external transaction) of the 

1 0 electronic records to another TCU. 

As described earlier, authentication certificates and public-key cryptography are 
used to support both user authentication and digital signature verification. The 
certificate is digitally signed by the issuing CA, a process by which the identity of the 
recipient is sealed with their public key. The CA asserts, in issuing a certificate, that the 

1 5 individual identified in the certificate is the holder of the matching private key used to 
digitally sign information objects or fragments thereof. 

This invention differs from other PKI-based e-commerce solutions since the PKI 
is only viewed as enabling and is not the sole basis of the trust environment. 
Sponsorship, contracting for membership, and enrollment are the principal factors. 

20 Although the certificate and use of public-key cryptography are viewed as enabling 
technology, certificates must uniquely identify and be tied to the specific users before 
they can be bound to that user's TCU account. 

Where certificates are employed, the account may only be activated once this 
binding between certificate and user account is completed. This binding may be as 

25 simple as adding the Certificate ID and Issuing CA to the user's account information or 
may use other information conveyed by the certificate such as components of the user's 
distinguished name (see ITU X.509 standard). The binding information may be 
conveyed in an enrollment form or extracted directly from the certificate as per TCU 
system security policy. A correspondence check may be used to ensure that the user 

30 description in the certificate matches that in the enrollment data whenever the 

certificate is used. The user's certificate is signed by the issuing CA and its integrity 
and authenticity are validated using the issuing CA's certificate and public key. The 
collective set of components used for identification must be provably unique. Once this 
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TCU account and user certificate binding is accomplished, the TCU need only know 
where to go to check certificate status. 

In CA centric environments, a single PKI, cross-certification, or creation of PKI 
bridges (a complex system that performs certificate status checking where multiple 
5 vendor products are used by numerous CAs) is required for interoperability. The 
common element is that all certificates are of equal value. Certificates may convey 
different trust levels and applications in an open environment must have the ability to 
interpret and use these trust levels differently. This philosophy can be characterized as 
"we will build roads that will take you anywhere you want to go". Users are vetted upon 
10 CA enrollment using a variety of criteria (e.g., a credit check, means of payment, cost of 
the certificate). 

A TCU, conversely, is only concerned with a known set of "approved CAs" and 
within that set only those certificates that are associated with its user accounts. Any 
other certificate will be ignored. This philosophy can be characterized as "the only 
1 5 roads that will be open to you will be those needed to conduct your business". Users 
are vetted twice, once to satisfy the CA certificate policy and a second time to prove 
that there is a business need for them to be enrolled with a TCU. Business rules 
enforced by the TCU can accommodate certificates that are issued at different trust 
levels. 

20 SUMMARY 

To date, all certificate status reporting services use a single means of reporting 
certificate status, be it CRLs, OCSP, LDAP, etc. This invention differs in that it enables 
interoperability with any CA or PKI for the purpose of retrieving and reporting certificate 
status. For the most part, it also reduces reliance on real-time continuous connectivity 

25 between the systems or TCUs and the CA certificate status reporting elements, by 
caching certificate status. 

In one aspect of Applicants' invention, a method of providing a CSS for checking 
validities of authentication certificates issued by respective CAs includes the steps of 
identifying information needed for retrieving a status of an authentication certificate from 

30 an issuing CA that issued the authentication certificate; configuring a connector based 
on the identified information for communicating with the issuing CA; communicating with 
the issuing CA according to the configured connector; and retrieving the status of the 
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authentication certificate. The issuing CA and the connector are designated on a list of 
approved CAs in a configuration store. 

A local date and time may be checked for whether they fall within a validity 
period indicated in the authentication certificate validity period. The issuing CA may be 

5 included in the list of approved CAs by vetting and approving the issuing CA according 
to predetermined business rules, and if the issuing CA is vetted and not approved, the 
issuing CA may be designated on a list of not-approved CAs in the configuration store. 
Vetting and approving the issuing CA may include registering a representation of a 
trusted authentication certificate with the CSS and adding at least the representation, 

1 0 status and a time-to-live data element to a local cache memory. A connector is then 
configured for retrieving the added status when the status of the trusted authentication 
certificate is queried. Communicating with issuing CAs may also be done according to 
a sequence of connectors. 

The method may further include checking a local cache memory for the status, 

1 5 and if the status is found in the local cache memory and the local date and time are 
within the validity period, retrieving the status from the local cache memory. If the 
status is not found in the local cache memory or if the local date and time are not within 
the validity period, the CSS establishes a communication session with a certificate 
status reporting component of the issuing CA, composes a certificate status request 

20 according to the configured connector, retrieves the status from the certificate status 

reporting component, closes the communication session with certificate status reporting 
component, and adds at least the authentication certificate's identification, status, and 
time-to-live to the local cache memory. 

Certificate status may be indicated by a CRL, and according to a publication 

25 schedule of the issuing CA, the CSS retrieves the CRL from a certificate status 

reporting component listed in the configuration store, the CSS clears a cache memory 
associated with the issuing CA, and the CSS determines the status of the 
authentication certificate from the CRL and stores the status in the cache memory 
associated with the issuing CA. 

30 Certificate status may also be indicated by a Delta Certificate Revocation List 

("ACRL"), and upon notification by the issuing CA that a ACRL is available, the CSS 
retrieves the ACRL from a certificate status reporting component listed in the 
configuration store; if the ACRL is a complete CRL, then the CSS clears a cache 
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memory associated with the issuing CA, determines the status from the CRL, and 
stores the status in the cache memory; and if the ACRL contains only changes 
occurring after publication of a full CRL, the CSS determines the status from the ACRL, 
and stores the status in the cache memory. 
5 In another aspect of Applicants' invention, a method of retrieving a status of an 

authentication certificate issued by an issuing CA in response to a query from a TCU to 
a CSS to validate the authentication certificate's status includes the steps of locating 
and reporting the status if the status is present and current in a cache memory of the 
CSS; and otherwise, performing the steps of obtaining a status type and retrieval 

10 method from a CSS configuration store; if the status type is CRL and the status is not 
found in the cache memory, then reporting the status as valid; if the status type is not 
CRL, then composing a certificate status request according to the status type; 
establishing a communication session with the issuing CA; retrieving the status from a 
status reporting component of the issuing CA using the obtained retrieval method and 

1 5 ending the communication session; interpreting the retrieved status; associating, with 
the interpreted retrieved status, a time-to-live value representing a period specified by a 
CSS policy for the status type; adding at least the authentication certificate's 
identification, status, and time-to-live values to the cache memory; and reporting the 
status to the TCU in response to the query. 

20 In yet another aspect of Applicants' invention, a CSS for providing accurate and 

timely status indications of authentication certificates issued by issuing CAs includes 
providing a status of an authentication certificate as indicated by a CRL when the 
certificate's issuing CA uses CRLs for indicating status. Otherwise, the status as 
indicated by a cache memory when the cache memory includes a status and a time-to- 

25 live data element is not exceeded is provided. If the time-to-live data element is 

exceeded, the status is cleared from the cache memory, and the status is requested 
and retrieved using a real-time certificate status reporting protocol when the status is 
not in the cache memory. At least the certificate's identification, status, and time-to-live 
data element are added to the cache memory, and the retrieved status is provided. 

30 A status use-counter data element may be added to the cache memory and 

incremented or decremented every time the certificate's status is checked. If the status 
use-counter data element passes a threshold, then the status is provided and the cache 
memory is cleared with respect to the status. A status last-accessed data element may 
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also be added to the cache memory, and the status last-accessed data element in 
conjunction with the status use-counter data element enables determination of an 
activity level of the certificate's status. 

When a request is made to the CSS to retrieve a status of a new certificate and 
the cache memory has reached an allocated buffer size limit, the CSS searches the 
cache memory for a lasted-accessed data element indicating an oldest date and clears 
the respective cache memory entry; and the CSS then retrieves the requested status, 
places it in the cache memory, and provides the requested status. 

In yet another aspect of Applicants' invention, a method of executing a 
transaction between a first party and a second party by transferring control of an 
authenticated information object having a verifiable evidence trail includes retrieving 
from a trusted repository an authenticated information object that includes a first digital 
signature block having a digital signature of a submitting party and a first authentication 
certificate relating at least an identity and a cryptographic key to the submitting party, 
executing the retrieved authenticated information object by the second party by 
including in the retrieved authenticated information object the second party's digital 
signature block, and forwarding the executed retrieved authenticated information object 
to a TCU. 

The TCU verifies the digital signatures and validates the authentication 
certificates associated with the digital signatures by at least retrieving status of the 
authentication certificates from a CSS. The TCU rejects a digital signature block if the 
respective digital signature is not verified or the status of the respective authentication 
certificate is expired or is revoked, and if at least one signature block in the information 
object is not rejected, the TCU appends the TCU's digital signature block and a date 
and time indicator to the information object and takes control of the object on behalf of 
the first party. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The various features and advantages of Applicants' invention will become 
apparent by reading this description in conjunction with the drawings in which: 

Figure 1 illustrates a TCU electronic information object validation process that 
employs the CSS; 

Figure 2 illustrates background CSS processing whereby CRLs and ACRLs are 
added to the certificate status store; 
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Figure 3 illustrates separate caching of parsed CRLs, OCSP responses, and 
status derived from other certificate status reporting methods; 

Figure 4 illustrates an extensible syntax for a signature block containing the 
example data elements where a digital signature is being applied to information object 
5 fragments and attached data (authenticated attributes); 

Figure 5 illustrates TCU interaction with a CSS and CSS retrieval of certificate 
status via the Internet from member and foreign CAs; 

Figure 6 illustrates a TCU user enrollment process terminating in a certificate 
status checking step, where digital signature validation demonstrates successful 
10 enrollment; 

Figure 7 illustrates a TCU user enrollment process where a foreign CA issued 
the user certificate, terminating in a certificate status checking step, where digital 
signature validation demonstrates successful enrollment; and 

Figure 8 depicts an automobile-leasing example that shows how a CSS can be 
1 5 utilized in electronic commerce. 

DETAILED DESCRIPTION 
The certificate status check is a critical element to a system or TCU acceptance 
of any electronic information object submission. In order for a submission to be 
accepted, the certificate status must be reported as valid. Querying for certificate 
20 status normally requires that communications take place between the TCU and the 
source of certificate status. The frequency of these communications will grow in 
proportion to the number of TCU submissions. 

Checking of certificate status may be a real-time requirement and status queries 
are performed on every submission. However, status may not be updated in real-time 
25 as is the case with CRLs. All CRLs are published at specified intervals, normally once 
or twice daily. CRL retrieval and repeated parsing can have a negative impact on 
system performance. This invention significantly reduces the direct computational and 
communication requirements by off-loading the bulk of the work to a CSS. A single 
certificate status protocol is implemented between the TCU and the CSS. This status 
30 protocol may have attributes similar to the IETF OCSP that allows an application to 

query a CA for the status of a single certificate and thus minimize processing overhead. 

The CSS is provided with and maintains sufficient information on the location, 
the means of communication and of processing certificate status for every CA that it 

12 
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needs to interoperate with. The CSS therefore makes it possible to stabilize and 
optimize the application design. The CSS advantageously parses and caches 
certificate status to minimize status response time to a TCU status query. The CSS 
therefore eliminates the need for any of the traditional forms of PKI interoperability. 
5 Potential compromise recovery is greatly enhanced since a TCU user account can 

easily be deactivated or a set of users eliminated by removing the CA from the CSS list 
of approved CAs. 

Use of Authentication Certificates: 

10 After logging into the TCU a participant may be asked to further authenticate 

themselves though use of public key cryptography and their authentication certificate. 
Such authentication may be associated with secure session establishment, requests for 
TCU services or the digital signing and submission of an electronic information object. 
Before anyone can interact with a TCU, four conditions must be met: 1 ) they 

1 5 must first be enrolled as a system user, 2) they must have been issued and be in 

possession of a public-key pair and their matching authentication certificate if they are 
granted more than read-only access, 3) certificates must be issued by an approved CA, 
and 4) the user's certificate must not have expired or be reported as inactive or 
revoked. This last condition normally requires that the TCU direct a query to the issuing 

20 CA to retrieve certificate status. Because there are a wide variety of standards and CA 
implementations for reporting certificate status, this is not an easy or simple task. 

As stated in the background section, normally some form of PKI interoperability 
is required when multiple CAs or PKIs are involved. This invention eliminates this need 
by creating a Certificate Status Service. CA cross-certification or bridging is 

25 unnecessary as the only knowledge needed by the CSS is the list of approved issuing 
CAs, their IP addresses or the like, and their means of reporting certificate status. 

To retrieve certificate status, a connector or program module is defined for each 
certificate status method. Every authentication certificate contains both subject (user) 
and issuer (CA) fields. The issuer field is used to direct a TCU query to the CSS that 

30 then checks its cache for the presence of the certificate's status. If status is present in 
the CSS cache, it is returned to the TCU. If status is not present, the CSS will invoke 
the appropriate connector to retrieve the certificate's status. Any number of methods 
will be used for reporting and retrieving certificate status: LDAP, OCSP, CRL, etc. 

13 
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To perform any TCU action, the user must first log into a TCU. Once successful, 
the user can create or select a transaction if they were granted such authority. If they 
have permission to submit electronic information objects, they may now do so. Upon 
receipt of an electronic information object, the TCU performs the necessary digital 
5 signature validation steps. A certificate status query will be composed and sent to the 
CSS. If a valid status is returned, the TCU will accept and store the submission as the 
authoritative copy, otherwise it will be rejected. 

Digital Signature Processing and Certificate Status Checking: 

10 Digital signatures may be applied to one or more fragments or the total content 

of an information object. Digital signatures may belong to the parties to the transaction 
or to agents who enable the transaction to achieve a state or status within the context of 
a business process. Digital signatures may in fact be applied to additional information 
relating to the task being performed. One such example might be the county recorder's 

1 5 notation on a property deed. Another might be the application of the signature of the 
party attesting to the authenticity of the information objects being submitted to a TCU. 
In this latter instance, the submitter is said to wrap or seal the information object in that 
their digital signature is applied to the full content, preventing any subsequent 
modification. 

20 Whenever a digital signature is applied, the signer will be requested to affirm 

their intent to be bound by their digital signature. This commit action, that is required by 
recent legislation, may take the form of readable text in a display window or splash 
screen, and may require invocation of a graphical button and/or logon to a 
cryptographic token that is also a cryptographic key and certificate store. The actual 

25 demonstration of said willingness to commit is through the use of a trusted application 
that computes the user's digital signature using the selected content and combines it 
with their authentication certificate to the form a signature block. The signature block 
may also contain authenticated and unauthenticated data elements. Authenticated 
data elements are included in the digital signature computation (e.g., local date-time) 

30 and may be considered protected by the digital signature (integrity). Unauthenticated 
data elements are added after the signature computation and are not protected. Figure 
4 shows a sample syntax that contains the data elements and layout of a signature 
block. It is not to be interpreted literally as it is only meant to be an illustrative example. 
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The information object and any signature blocks may be advantageously placed 
in a wrapper (S/MIME) or at tags in an extensible information syntax (XML, HTML, 
XHTML) for handling convenience and to facilitate information processing. This data 
structure is then sent to the TCU for validation. Conversely, the signature block(s) may 
5 be sent independently to the TCU to be affixed to the actual source record which never 
leaves the TCU. In the latter case, each signature block is validated separately. 

The process for digital signature validation differs at the time of submission, from 
that performed thereafter. A four-step validation is performed the first time the TCU 
sees a digital signature: 1 ) verify the digital signature, a process that proves that the 

10 content protected by the digital signature has not been altered during transmission; 2) 
check that the current TCU time falls with the allowable validity period of the individual's 
authentication certificate ("not before", "not after"); 3) request and retrieve certificate 
status from the issuing CA, CRL distribution point, or another approved source of 
certificate status using the locally assigned CSS; 4) validate that the TCU user account 

15 information agrees with that conveyed in the certificate and that the requested action is 
authorized in the TCU rules database. For a submitter of the information object, the 
process adds one additional step. This fifth step checks that the submitter's identity 
matches that of the party who established the current session with the TCU. If all tests 
succeed, the action is allowed and/or the information object is accepted and held by the 

20 TCU on the behalf of its owner. If any step fails, remedy is initiated. 

After this initial certificate status check, the trust environment of the TCU 
maintains the authenticity and integrity of all held information objects. It is not 
anticipated that any additional certificate status check will be needed unless a new 
version of the document is submitted. 

25 Two aspects of this invention differ from the normal course of PKI 

implementation. The first is that this invention is based on the existence of an 
application, namely the TCU (or any application/system requiring certificate status 
validation) and its ability to create and maintain electronic original source records. The 
second is that "issuing CA" need only be identified as complying with the policies 

30 governing the trust environment and that neither CA cross-certification nor PKI bridging 
is required. The necessary justification for "issuing CA" inclusion is a documented 
business relationship. During the TCU enrollment process, a user account is created 
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that references user specific certificate information that in effect binds the user account 
with the user's authentication certificate. 

TCU Use: 

5 Typically once an organization agrees to utilize the services of a TCU, control 

over access to that organization's transactions is granted to agents of that organization. 
The organization's agents then identify a set of individuals whom they will empower to 
perform selected actions with regard to the organization's transactions. All actions 
require that the user have an account with the TCU, that the account be activated, and 

1 0 that the user have a logon identity and be able to provide an appropriate password or 
response to a challenge phrase. In addition, each transaction, which is composed of a 
set of versioned electronic original source records, has a set of permissions that govern 
user access at different steps in the business process. This is exemplified by the 
granting and removal of rights to transaction records as the transaction proceeds 

15 though the normal course of business, i.e., inception through permanent retention or 
destruction. If permitted, only logon to the TCU is required to view an electronic source 
record. However, any systems level action or the introduction or changing of an 
electronic source record requires the individual to either further authenticate themselves 
by using public key cryptography or by applying their digital signature and 

20 authentication certificate. In all instances, the identity of the individual must be 

validated. Where digital signatures are employed, this entails: 1) that the user has 
appropriate access permissions, 2) decrypting the digital signature and verifying the 
contents over which the underlying hash or message digest has been applied have not 
been altered, 3) checking that the time of submission falls within the certificate validity 

25 period, and 4) checking that the user certificate is still valid. 

Certificate status checking requires that the issuing CA or a certificate status 
responder be queried. Since this step must be taken with every authenticated action or 
electronic source record submission, communication bandwidth may become excessive 
and potential exists for delays, backlogs, and rejections due to unanswered or slow 

30 status responses. This invention addresses these and other high assurance aspects of 
operating a TCU and ensuring the validity of all parties interacting with the TCU. 

In the highly assured environment in which the TCU is operated, certificate 
status checking is only needed when a service is requested by a qualified user. For 
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information objects, certificate status need only be checked at the time of submission. 
If all digital signatures are determined to be valid, the information object is deemed 
authentic thereafter. Security and procedural practices and methods are in place at the 
TCU to prevent malicious actions and hardware failures that result unauthorized 
5 document alteration or loss. Every submission results in creation of a new version of an 
electronic source record. The TCU is charged with maintaining knowledge as to which 
is the latest version of the source record. This version may be identified as the 
electronic original and as a transferable record. The TCU demonstrates its assumption 
of control of an original source record by adding a reliable date-time stamp to the 

10 source record and then by applying its digital signature and appending its certificate. A 
wrapper may be applied to the source record for security and processing expediency. 
Although this versioning process creates a standalone authenticated trail-of-evidence 
and custody, separate redundant audit records are maintained for corroboration. 

Applicants 1 CSS overcomes the described limitations that persist today with PKI 

15 and e-commerce. Source information required to obtain certificate status from member 
CAs is registered with the CSS when they are created. Source information for foreign 
approved CAs may be entered during the user enrollment process. CSS retrieval 
information is required for every certificate status source. There are several types of 
certificate status sources and the CSS is required to have a connector or method for 

20 each type registered. 

One method used by some CAs to convey certificate status is the CRL, which 
includes a list of revoked certificates and the reason for their revocation, the issuer of 
the CRL, when the CRL was issued, and when the next version of the CRL will be 
published. Every CRL is signed by the issuing CA or a designated signer to assure its 

25 integrity and authenticity. Certificates are removed from the CRL once their validity 
period is exceeded. 

Where CRLs are used, the CSS retrieves the latest rendition of the CRL from the 
CA distribution point, e.g., an X.509 v2 CRL profile (IETF RFC2459, Jan 99), validates 
its signature, parses it, and creates a cache to store the results. The CSS uses a CA's 
30 CRL publication interval to govern when it performs the next CRL download. Every 
CRL contains a validity field that is normally set to allow some leeway in performing 
downloads. This allows for communications congestion and CA downtime and will 
force the CSS to require remedial action if this interval is exceeded. Such remedy may 
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include revalidating any submissions that are associated with a newly added revoked 
certificate. Each new CRL supersedes the previously loaded CRL. The exception to 
this rule is for delta CRLs procession. The contents of a delta CRL are appended to the 
current cache contents. The delta CRL BaseCRLNumber refers to the most recent full 
5 CRL issued. Delta CRLs are published at shorter intervals (minute, hour) and only 
when a certificate revocation has occurred since the last full CRL. The CSS is 
responsible for retrieving CRLs and delta CRL based on publication interval or 
notification and not to exceed the interval established in the TCU security policy. 
A second method used by CAs to distribute certificate status is the OCSP. 

10 Where OCSP is used the CSS queries the OCSP responder when asked for certificate 
status. OCSP responses are signed to guarantee their integrity and authenticity. The 
CSS parses the OCSP response and adds certificate details and status to another 
cache. A time-to-live flag, determined by local TCU security policy, is included with and 
determines when the entry will be removed from the cache. This feature is aimed at 

15 minimizing communications overhead when several information objects are be 

uploaded by the same party/entity to the TCU in a short interval. The time-to-live flag 
will usually be significantly shorter (e.g., 5 minutes) than the normal CRL publishing 
interval (twice daily, daily). The CSS may check certificate status again, if more than 
one information object was processed, prior to purging certificate status from the cache 

20 to ensure that certificate revocation has not occurred. If certificate revocation has 
occurred during the time-to-live interval, then the owner organization point of contact 
must be notified. Several other query methods exist, but will not be described for 
brevity. Be it understood that they will each require a connector and potentially a 
separate cache when they are utilized. 

25 Figure 1 shows the process flow for creating an electronic original. For the 

purposes of description, the information object is assumed to be a sales contract. A 
copy (unexecuted) of the electronic information object is retrieved from the TCU or from 
a document preparation system and is digitally or holographically (handwritten) signed 
by appropriate parties. Having overseen the execution process, the owner's agent uses 

30 a trusted application to digitally sign and wrap the information object and send it to a 
TCU. 

Having previously created, executed or retrieved the electronic document, a 
submitter digitally signs and submits it to the TCU as in step 101 . In this eSeal process, 
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a wrapper that contains the signed content and digital signature block(s) that further 
contain the digital signature(s) and certificates(s) of the submitter and any other 
signatory is formed. There are five processes represented in Figure 1: (1) action when 
an invalid digital signature(s) and/or revoked certificate(s) is found, (2) certificate status 
5 checking where status is locally cached, (3) certificate status checking where certificate 
status has to be retrieved, (4) CRL retrieval and processing, and (5) creating an 
eOriginal when the eSeal document is determined to be authentic. In step 103 the TCU 
receives the eSealed electronic document. In step 105 the TCU validates that the 
submitter has authority to add the electronic document to a selected account and/or 

10 transaction. In step 107, the TCU cryptographically verifies any digital signatures 

included in the electronic wrapped digital electronic document. The public key, found in 
the signer's X.509 authentication certificate, is used during the verification process. In 
step 109, the certificate validity period is extracted from the signer's authentication 
certificate, and in step 1 1 1 , the validity period is checked against the current date and 

1 5 time. If any of the before mentioned tests fail, the submission is rejected in step 1 1 3 
and a negative acknowledgment may be sent in step 114. The action is logged in step 
117. 

If all tests succeed, then certificate status for each certificate contained within the 
wrapper is requested from a CSS in step 119. In steps 121 and 123, certificate status 

20 is checked to see if it is present in a certificate status store. In step 125, certificate 
status is retrieved, and certificate validity is checked in step 127. If any certificate is 
found invalid for any reason, the submission is rejected in step 1 13, a negative 
acknowledgment may be sent in step 115, and the action is logged in step 117. The 
submitter is expected to seek remedy. 

25 If in step 127 all digital signatures and certificates are determined to be valid for 

the submission, then in step 129 the TCU applies another wrapper that includes a date- 
time stamp and TCU digital signature block. The TCU then assumes control of the 
submission as an electronic original record on behalf of the owner of record. In step 
131, the TCU places the electronic original in protected persistent storage, in step 133, 

30 the TCU sends a positive acknowledgment, and in step 117, the TCU logs the actions 
just completed. 

If in step 123 it is determined that the certificate status is not present in the 
certificate status store, then the CSS in step 1 35 retrieves the issuing CA field from the 
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certificate under test. In step 1 37, the CSS checks to see that the issuing CA is on the 
approved CA list, which may be maintained and accessed by a CA Connector Store in 
step 139. If the CA is not listed, then an invalid status is returned and the process 
resumes at step 125 and proceeds through steps 127, 113, 115, and 117, resulting in 

5 rejection of the submission and transmission of a negative acknowledgment and log 
entry. If the issuing CA is found on the approved CA list in step 137 and in step 141 it 
is determined that the certificate status reporting mechanism is a CRL, then a valid 
status indication is returned to step 125. If the CA is known and status is not present 
for the subject certificate, but the status mechanism is a CRL, then it may be assumed 

10 that the certificate status is valid, providing a CRL exists and is current for the CA. The 
process then proceeds through steps 127, 129, 131, 133, and 117, resulting in the 
creation of an electronic original, the transmission of a positive acknowledgment, and a 
log entry for the actions just completed. 

If in step 141 the certificate status reporting mechanism is determined not to be a 

1 5 CRL, then the connector information obtained in step 137 is used to query the 

certificate status reporting mechanism. Contained in the connector description is all 
configuration information needed to query the appropriate certificate status repository, 
be it a CA, a directory, or any other type of certificate status repository. The status 
stores associated with steps 145, 147, 149, and 151 (i.e., respectively, an LDAP 

20 directory, an OCSP responder, a database, and a server) are examples of such 

repositories. In response to a query in step 143, one of these responds with certificate 
status information, and the status is added to the certificate status store in step 153. 

Upon addition in step 153, the certificate status in-store process resumes at step 
121 and continues through steps 123, 125, and 127 to a conclusion where the 

25 submission is either accepted (steps 1 29, 1 31 , 1 33, 1 1 7) or rejected (steps 113,115, 
117). 

CRLs are published in step 155 at predetermined intervals and in step 157 as 
needed when a suspected compromise is reported and policy requires an immediate 
response. This process is further described in Figure 2. 
30 If the CA is known and status is not present, and the status mechanism is other 

than a CRL, the Certificate Status Service selects a connector and queries the 
certificate status mechanism (step 143). The connector contains the necessary 
information that makes status retrieval and interpretation possible. Any of the sources 
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of real-time certificate status depicted in steps 145 - 151 will respond to a certificate 
status query with current status, but this process is not limited only to those sources. 
Status is received and added to the Certificate Status Store in step 153. When status 
is added, a response is generated and action returned to step 123, with the processing 
of status resuming in step 125 and completing as described previously. 

Referring now to Figure 2, the CSS performs CRL retrieval as a background 
process. A CRL contains a list of all revoked or suspended certificates until the current 
date and time is beyond the validity period contained in the certificate. Suspended 
certificates are treated as if they have been revoked, but they may be reinstated which 
results in their removal from the CRL. Revoked certificates cannot be recovered. 

In step 155, a CA Administrator configures the CA to publish CRLs at 
predetermined intervals. In step 157, the CA Administrator may also publish a Delta 
CRL as dictated by the local certificate or security policy. The CA Administrator or CA 
will push notice on publication of a Delta CRL. A Delta CRL may be generated 
whenever a certificate is revoked or suspended during the interval between publications 
of the full CRLs. Delta CRLs may contain a complete list of revoked CRLs. In step 
201 , CRLs and Delta CRLs are published to a CRL repository or directory. 

In step 203, the CSS retrieves the CRL publication schedule or Delta CRL 
notice, and step 205 represents a timer used for scheduled retrieval. The timer also 
allows retrieval based on the "next update" field contained in all CRLs. In step 207, the 
CRL or Delta CRL is retrieved from the CRL repository. In step 209, the CRL or Delta 
CRL is parsed prior to being added in step 1 53 to an appropriate cache or list in the 
Certificate Status Store in step 121 or directory based on the established schedule or 
upon notification. Parsing the CRLs allows for easier management and reduced 
overhead in CRL entry lookup. Steps 119, 123, 125, 135, 137, and 141 of the CSS are 
illustrated in Figure 2 for completeness, and are implemented as described in 
connection with Figure 1. 

Referring now to Figure 3, the Certificate Status Store contains a number of 
caches that hold certificate status from different reporting mechanisms. The caches 
(five of which are depicted in Figure 3) may map to individual CAs (caches 301, 303) or 
collections of CAs (caches 307, 309). For real-time reported status, the status remains 
in the cache until space is needed (e.g., least frequently used) or based on a policy 
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requirement (e.g., hold for only a specified time interval). Status is normally purged 
once the criterion is exceeded. 

The purpose of the caches is to hold certificate status for a policy dictated 
period, thereby reducing communications overhead required during certificate status 
5 and CRL retrieval. The CSS therefore can bridge communications outages. 

CRLs may be parsed and the individual revoked certificate statuses placed in a 
cache to reduce computational overhead resulting when the CRL has to be checked 
repeatedly. This is depicted by the caches 305, 307. The contents of the cache are 
replaced whenever a new full CRL is retrieved. 

10 Referring now to Figure 4, an example syntax is shown representing some of the 

more important data elements that need to be included in a digital signature block. 
Figure 4 is a free form example of data elements that make up a digital signature where 
the signature is applied to multiple message fragments and a date/time stamp. This 
example is meant to be illustrative of the syntax that may be used for a digital signature 

1 5 block. It may be noted that the <CumulativeHashValue> data element is applied to 

HashValues of one or more fragments or the total content and any Authenticated Data. 

Figure 5 depicts a secure communications architecture showing the building 
blocks that support the Certificate Status Service. The figure shows the interaction 
among three CAs, the CSS, and the TCU. The CSS is preferably placed local to the 

20 TCU to guarantee high availability. Its primary purpose is to provide the TCU with a 
common interface and to ensure secure and timely provision of certificate status 
information. Its secondary purpose is to ensure a guaranteed level or quality of service 
by managing communication and computational overhead required in maintaining 
certificate status information. 

25 As seen in Figure 5, the CSS server and the TCU, with a suitable 

communications router and hub, are advantageously disposed behind a 
communications firewall. The router and hub direct information to the CSS and TCU as 
appropriate. Some of this information comprises eSeal submissions that are directed to 
the TCU as described above through a network such as the Internet from a User Client 

30 Application. Also depicted are CSS and TCU communications via OCSP. 

Figure 5 also depicts three CAs in different exemplary environments behind 
respective communication firewalls. An Enterprise CA might comprise a server that 
interfaces with a Lease Industry CA enclosed by the dashed lines. A Foreign PKI or 
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Responder might comprise a server that interfaces with entities such as a PKI, CA, and 
certificate status responder. A Hierarchical Member PKI might include a server that 
interfaces to entities such as a V3 LDAP for CRLs and certificate status, a Root CA, 
and CAs for the mortgage and lease industries, lenders, closing agents, and title 
5 insurers. 

Figures 6 and 7 depict the use of the Certificate Status Service during the user 
(subscriber and entity) enrollment process for both member CAs and foreign CAs, 
respectively. A member CA is one that is trusted to issue user certificates. Foreign 
CAs are those operated by outside entities and need to be approved prior to their 

10 certificates being used in conjunction with TCU activities. User identity authorization 
needs to be rigorously enforced by all CAs or delegated to organization agents. An 
additional requirement is that a user's certificate needs to be directly associated or 
authorized for use with one or more subscribing organizations' accounts before the TCU 
can grant access to that user. Once this is accomplished, the TCU will accept the 

1 5 user's digital signature and rely on the CSS for certificate status validation. 

In Figure 6, the TCU enrollment process starts at step 601 with receipt by an 
organization's administrator/agent of user enrollment information from a sponsor. In 
step 603, this administrator/agent is charged with validating the sponsor's authority to 
make the request. Sponsors are normally only given control over their accounts. In 

20 step 605, the administrator/agent enrolls the user with the TCU, setting up a user 

account. In step 607, the administrator/agent may then assign transaction privileges to 
the user. Transaction privileges may include abilities to submit, version, transfer, etc. 
electronic originals and other source records. 

In step 609, a cryptographic token (digital signature mechanism) is initialized, 

25 and in step 61 1 , a public-key pair is generated on the token. In step 613, a certificate 
request is created, and in step 615, the request is sent to the organization's CA. In step 
617, the certificate is retrieved and placed on the token. In step 619, the certificate is 
bound or associated with the user's TCU account. 

In step 621 , the user's identity is validated, for example by appearing in person to 

30 the organization's administrator/agent who can personally validate the user's identity. 
Normally, at least two forms of identification would be required. Since user participation 
is sponsored, this should be sufficient except for high valued transactions where 
someone known to the administrator/agent may be asked to vouch for the user's 
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identity, in step 623, the user is asked to sign a contract agreement whereby the user 
agrees that use of the user's digital signature is binding. In step 625, the user is given 
an application user manual and whatever instruction is deemed necessary. In steps 
627 and 629, the user is provided with logon IDs, temporary passwords, and the 
5 cryptographic token. 

In step 631 , the user logs onto the system, and in step 633, submits a test 
document to the TCU. In step 635, the TCU validates the user's digital signature and 
certificate. In step 637, the TCU queries the CSS for certificate status information. In 
step 639, the TCU receives status and proceeds accordingly. If the received certificate 

10 status is valid, enrollment completes at step 641 , and the user is able to access and 
use the TCU. If the certificate status is invalid, enrollment terminates in step 643, and 
the administrator/agent determines the cause of the error and institutes remedy, which 
may involve repeating some or all of the outlined enrollment process steps. The 
reliable process outlined in Figure 6 ensures that the enroilee is fully enabled at 

15 completion. 

In Figure 7, the user is allowed to use a cryptographic token previously issued by 
a foreign CA if policy dictated conditions are met. As described above, enrollment 
steps 601 through 607 are followed. User identity verification and contract steps 621 
through 627 are also followed as described above. 

20 Since the user already has a token, the process deviates from that described in 

Figure 6. In step 701 , the user places the token in a compatible reader and logs on. In 
step 703, an administrator application retrieves the user's certificate from the token. In 
step 705, the certificate information is displayed and the Issuing CA identification 
information is obtained. The CA information is used in step 707 to verify that the CA is 

25 on an approved list. If the CA is not on the approved list, the CA information is provided 
to the TCU administrator in step 709, and the administrator checks with an Application 
Policy Authority in step 71 1 for permission to continue enrollment. Only the Application 
Policy Authority can authorize adding a foreign CA to the approved list. 

If permission is denied in step 713, enrollment terminates in step 649, giving the 

30 user three options. One is to ask for and use a token issued by a member CA. Another 
option is to request a review of the CA rejection decision. The third option is to ask for 
the names of previously approved foreign CAs. 
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If the Issuing CA is approved but not on the list in step 713, in step 715 the 
administrator adds the CA and connector information to the approved list, configuring 
the CSS to retrieve certificate status from the CA. 

In step 619, the user's certificate is bound or associated with the newly created 
5 user account. As in Figure 6 and steps 631 through 639, the user is asked to make a 
trial submission to the TCU to validate that the account has been set-up correctly and 
that the user can access the TCU. If the CSS returns valid status information, then 
enrollment completes at step 641. If the CSS returns invalid status, then the 
administrator determines the cause of the error and institutes remedy, which may 

10 involve repeating some or all of the enrollment process steps described above. The 
most likely cause of failure may relate to the CSS's being able to reach and correctly 
retrieve certificate status from the foreign CA. 

The CSS plays a vital role in validating that the user certificate and issuing CA 
are both authorized in accessing a TCU or other system. If an issuing CA is removed 

15 from the approved list and its connector configuration data deleted, all associated users 
are denied further access to the TCU. It should be understood that the CSS can work 
with other applications and systems that require certificate status, including applications 
and systems that require inter-working with multiple PKIs and CAs. 

For example, another use of the CSS is to provide status for trusted 

20 authentication certificates, including self-signed certificates, where an agreement exists 
between the client seeking services and the application operator. A representation of a 
trusted certificate (e.g., PEM, certificate ID, applied digital signature) is cached by the 
CSS, and status is queried using a trusted-certificate connector. This allows the 
application to have a single certificate status means regardless of whether the 

25 certificate was self-signed or issued by a CA. This trusted-certificate method may be 
used where a small number of controlled certificates are used by a community rather 
than querying the community's CA or CAs. Thus, it will be appreciated that the terms 
"CA" and "issuing CA" as used in this application encompass such an accepted issuer 
of self-signed certificates as well as conventional CAs. 

30 Furthermore, the CSS may use a combination of connectors to retrieve 

certificate status. At least one connector may be "virtual", such as that just described 
for use with trusted certificates. The CSS invokes connectors in a predetermined, e.g., 
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ordered, sequence until certificate status is acquired. This method enables creation of 
a hierarchy of status sources (e.g., most-trusted to least-trusted). 

Figure 8 depicts an automobile-leasing example that shows how the CSS is 
utilized in e-commerce. The automobile dealer or the dealer's representative, hereafter 
called the dealer for simplicity, was issued a respective authentication certificate by an 
Automotive CA, which is depicted as a computer. The car's lessee, who may be 
present at the car dealership, was issued a respective authentication certificate by a 
Bank CA. A remote lessor was issued a respective authentication certificate by a 
Financial CA. Alternatively, either lessee or lessor may have created a self-signed 
certificate, which the dealer registered with the leasing application and the CSS, for 
example because the lessee is a regular customer of the dealer. 

As explained in this application, the CSS retrieves and reports status for these 
and other certificates using any certificate status reporting means that uses an 
approved status reporting protocol. In Figure 8, it is assumed that Automotive CA and 
Financial CA use OCSP, that the Bank CA uses a CRL, and that the dealer and lessees 
have some forms of token (e.g., PKCS#1 1 , PKCS#12, browser key store, etc.) that 
contain their certificates and cryptographic signing means. It will be appreciated that 
Figure 8 is just an exemplar of execution of a transaction; more or fewer CAs may be 
connected as necessary with communications as necessary for the particular 
transaction. 

In step 801 , the dealer either originates the lease contract or retrieves it from a 
leasing application, such as a computer program running locally at the dealership or 
remotely at a remote site, e.g., on an Application Server. In step 803, the dealer 
orchestrates the execution of the lease by the lessee and lessor. The lease may be 
displayed to both the local lessee and the remote lessor at this time, and the dealer 
may be called on to answer any questions and make corrections if needed. The dealer 
may arrange for displaying the lease to the lessor by providing a URL (uniform resource 
locator) to the lessor that enables the lessor to review and execute the lease, with the 
executed version returned to the dealer. After local signing by the lessee and the 
dealer, for example with a tablet pc that captures the lessee's digital signature on the 
lease, and remote signing by the lessor, the lease is transmitted (step 805) to an 
Electronic Vault, which is shown in communication with the Application Server. The 
digital signing by the lessee and dealer is advantageously dynamic, with the Application 
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Server updating the displays by applying a "digitally signed by" indicator to the 
displayed image(s). The actual digital signatures are preferably not displayed. 

It will be recognized that the Application Server and associated Electronic Vault 
may be used by the dealer to stage the contract for remote signing by the lessor. In 
5 steps 807 through 81 1 , the lessor retrieves the lease from the vault, agrees to the terms 
of the lease by digitally signing it, and returns its digitally signed version to the vault. 
Steps 807 through 811 illustrate both multi-site collaboration and asynchronous 
transaction processing. 

In steps 813 through 817, the received electronic document(s) (the lease) are 

10 checked for digital signatures, and if any are found, the digital signatures are verified 
and the respective authentication certificates are validated. In step 817, the local time 
is checked to ensure that it falls within the validity period(s) of the certificate(s), and in 
step 819, the CSS is queried for the status of the certificate(s). In response in step 821 , 
the CSS first checks its local cache memory or data store for certificate status, and if a 

15 certificate's status is present and current, the CSS returns the certificate's status as 
"active" in step 827. In step 823, if certificate status is not present or not current, the 
CSS queries the issuing CA using the connector type created for this purpose. In step 
825, the issuing CA, e.g., the Bank CA, or its status reporting means (e.g., directory) 
returns status to the CSS, preferably using the same connector, and in step 827, the 

20 CSS reports the queried certificate's status back to the Application Server. 

Assuming all digital signatures and certificates are verified and validated, proving 
the electronic document authentic, the Application Server assumes control of the 
electronic document and saves it in the Electronic Vault as a new version in step 829. 
Thus, it will be seen that, with the proper characteristics, the Application Server and 

25 Electronic Vault cooperate as a TCU. In step 831 , the new version is designated as an 
authoritative copy, an Electronic Original that may also be a transferable record, by 
appending a date-time stamp and applying the TCU's digital signature to the document. 
As long as at least one digital signature on a document is valid, this step takes place. 
In step 833, if any digital signature or certificate fails to pass all tests, the dealer 

30 is alerted to seek remedy, which typically involves repeating steps 801 through 829 until 
valid replacement digital signatures are applied. The remedy process cannot be 
completed if the status of a signer's certificate is revoked or expired until a new 
certificate and cryptographic material are issued. 
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It will be understood that an information object, such as a lease for an 
automobile, may be presented in an electronic form, e.g., XML, PDF, PKCS#7, 
S/MIME, etc., that enables placement and detection of digital signatures and prevents 
unauthorized modification. Many of these forms therefore can be considered as 
5 providing security wrappers or envelopes for the included information. 

It will also be understood that the CSS can be used to check status of certificates 
regardless of key usage. Such certificates include, but are not limited to, those for 
which the primary use is not identity and authentication, e.g., key agreement/exchange, 
certificate signing, CRL signing, key encryption, data encryption, encrypt only, decrypt 

10 only, and secure sockets layer (SSL). Accordingly, it will be understood that as used in 
this application the term "authentication certificate" generally encompasses such 
certificates that are not used for identification. 

In addition, a CSS connector can advantageously embed more than one 
certificate status check in a single communication. Among other things, this capability 

1 5 may be used in validating some or all of a chain of user/entity certificates and CA 
certificates, e.g., a hierarchy of CAs from a Root CA down to an issuing CA. This 
provides additional assurance that all CAs in the certificate path are still valid. 

This application has described a method for configuring a Certificate Status 
Service (CSS) that includes the steps of determining setup information needed to 

20 retrieve certificate status for a requisite issuing CA, identifying a connector compatible 
with a certificate status lookup technique used to retrieve certificate status from the 
issuing CA, configuring the connector with setup and communications parameters 
specific to the selected connector and the issuing CA, and setting up a CSS mapping 
between the issuing CA and the connector. The CA designation and connector is 

25 added to a list of approved CAs in a configuration store. 

A method for executing a transaction by transferring authenticated information 
objects having respective verifiable evidence trails includes the step of retrieving, by a 
first party from a trusted repository, an authenticated information object. The 
authenticated information object includes a first digital signature of the submitting party, 

30 a first certificate relating at least an identity and a cryptographic key to the submitting 
party, a reliable date and time, a digital signature of the trusted repository, a certificate 
relating at least the identity and cryptographic key to the trusted repository; the digital 
signature and certificate of the submitting party having been validated by the trusted 
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repository at submission attesting to the information object's authenticity; and the 
authenticated information object having been placed in storage as an electronic original 
information object placed under the control of the trusted repository. 

The transaction execution method further includes the steps of requiring any 
5 signing entity to commit to use of and to be bound by their digital signature prior to the 
act of signing, executing said information object by any party, consists of inclusion of at 
least the digital signature and authentication certificate of the signing party, creating a 
signature block that contains at least the digital signature and authentication certificate 
of the signing party, associating the signature block with the information object, 

10 repeating the previous execution steps where multiple entities digitally sign the 

information object and/or wrapper, and forwarding the digitally signed and/or wrapped 
information object to a TCU. The TCU verifies every digital signature and validates 
each associated authentication certificate and retrieves status from a CSS. The 
signature blocks are rejected if the signer's digital signature does not verify or a signer's 

15 authentication certificate has expired or is reported to be revoked. Rejection of any 
signature block results in a request for a replacement signature block or initiation of 
remedy. If at least one signature block is determined to be valid, the TCU appends its 
own signature block, also containing reliable date and time, to the subject information 
object, creating an electronic original which it holds and controls on behalf of the owner. 

20 Creating a digital signature block may include the steps of computing one or 

more content hashes for the one or more information object fragments or for the whole 
information object, computing a hash over the one or more content hashes and any 
appended data, such as the local date and time, signing rationale, or an instruction, 
encrypting the computed hash using the signing party's private key, thereby forming the 

25 signer's digital signature, and placing the signer's digital signature in the signature block 
along with the signer's authentication certificate. If the appended data includes a local 
date and time, creating a digital signature block may further include the steps of either 
displaying the local date and time, requiring a signer to affirm that the date and time are 
correct, and correcting the local date and time if either is incorrect, or relying on a 

30 system date and time if these are set by a trusted time service and local date and time 
is protected from tampering. The local date and time can be checked to ensure that it 
is accurate and that it falls within the user's authentication certificate validity period and 
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that the local data and time is not before and not after the dates and times specified by 
the validity period. 

Remedy of a digital signature that fails to verify requires the digital signature to 
be recomputed and the signature block to be retransmitted. Remedying a violation of 

5 authentication certificate validity period includes notifying the user that the user's 
certificate has expired and must be renewed and notifying the transaction owner that 
the transaction is incomplete. 

Placement of one or more signature blocks and the information contained therein 
is specified by at least one signature tag. One or more handwritten signatures and 

10 dates are digitized and used for information object execution, and placement of the 
signatures and dates is specified by at least one signature tag. One or more signature 
blocks can be sent to the TCU separately along with the designation of the 
corresponding signature tags and the TCU can validate every signature block sent 
independently or as a group. If either the digital signature verification or authentication 

1 5 certificate validation step fails, the TCU rejects the signature block and may request 
remedy, and if the signature block validation step succeeds, the TCU places the 
signature block at the indicated tag. To signature blocks sent separately, the TCU may 
add a reliable date and time to each signature block. According to business rules, the 
TCU appends its own signature block that contains a reliable date and time in a 

20 wrapper that encompasses the subject information object and inserted signature block 
fields, thereby creating an electronic original information object. Multiple user 
signatures blocks may be added within a wrapper, and wrappers can be recursively 
applied to implement other business and security processes. 

The TCU may validate the digital signature(s) and authentication certificate(s) 

25 present in a signature block(s) that is/are to be contained within or is/are to be added to 
content of an electronic original information object by checking in the business rules 
database that the signing entity identified by the authentication certificate has authority 
to perform the requested action, verifying the signing entity's digital signature, checking 
that certificate validity period overlaps current reliable date and time, checking that the 

30 conveyed local date and time falls within allowable deviation with the TCU date and 
time, and checking certificate status using a CSS. If any of these steps results in an 
invalid or false output, the digital signature is deemed invalid, the requested action is 
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disallowed and remedy sought; otherwise, the digital signature is deemed valid and the 
requested action is allowed. 

Registration of an issuing CA with a CSS may include the steps of vetting and 
approving the issuing CA for inclusion in a CSS knowledge base as "authorized" based 

5 on industry or organization business rules and system policy. If the vetting step fails, 
the issuing CA is added to the CSS configuration store as "not authorized" and/or CA 
registration terminates; otherwise, the issuing CA is added as "authorized", and the 
communication parameters (IP address, SSL key and certificate) and the method used 
for reporting certificate status (OCSP, CRL, LDAP) are added to the CSS configuration 

1 0 store, and the connector to interpret certificate status is added if not already 

implemented. In this way, the CSS enables interoperability between a system or TCU 
and a diverse set of certificate status responders. 

Certificate status checking advantageously employs a CSS for establishing 
communications, retrieving and caching certificate status from approved certificate 

1 5 issuing CAs. When CSS receives a certificate status query from a system or TCU, the 
CSS first checks its local cache to see if the certificate status is present and if found 
and within the time-to-live interval, returns status. If certificate status is not present or 
outside the time-to-live interval, then the CSS retrieves status by first requesting 
connection information from its configuration store. The CSS then establishes a 

20 communications session with certificate status reporting component identified in its 

configuration store. The CSS composes a certificate status request as per the method 
contained in CSS configuration store, and the CSS retrieves certificate status from the 
certificate status reporting component and closes session with component. The CSS 
adds at least the certificate's ID, certificate status and time-to-live to its cache and 

25 returns certificate status to the requesting system or TCU. 

The certificate status reporting may be based on a CRL and processing of the 
CRL. According to the issuing CA's publication schedule, the CSS retrieves the CRL 
from the certificate status reporting component listed in the CSS configuration store. 
The CSS clears its cache memory associated with the issuing CA, parses certificate 

30 status from the CRL, and places the certificate status into its cache associated with the 
issuing CA. Upon notification by an issuing CA that a CRL is available, the CSS may 
retrieve the. CRL from the certificate status reporting component listed in the CSS 
configuration store. Where it is required by standards that the. CRL is a complete CRL, 
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then the CSS clears the cache associated with the issuing CA, parses the CRL, and 
places the certificate status and related information into the cache associated with 
Issuing CA. Where the CRL contains only changes occurring after publication of a full 
CRL, the CSS parses certificate status from.the CRL and places certificate status and 

5 related information into the cache associated with issuing CA. 

Using a CSS to obtain certificate status that allows a user, system or TCU to use 
a single means for obtaining certificate status can include the steps of querying the 
CSS for the status of an authentication certificate present in a signature block on an 
information object, where the status query may use a single means (e.g., OCSP), 

10 translating the status query to a form required by the issuing CA, and retrieving and/or 
reporting certificate status. If certificate status is revoked, the signature block is not 
used and remedy is required; if the digital signature verifies and certificate status is 
valid, the signature block is added to the electronic original information object. 

The TCU can query the CSS to validate a signer's authentication certificate 

15 status by locating and reporting certificate status if the status is present and current in 
the CSS cache/data-store, and getting type and means for retrieving certificate status 
from the CSS configuration store. If the particular certificate status method is a CRL 
and the specified certificate's status is not found in the issuing CA cache in the CSS, 
then the CSS reports the certificate status as valid. If the certificate status method is 

20 not a CRL, then the CSS composes a certificate status request as per the method 

contained in CSS configuration store, and establishes appropriate communications with 
the issuing CA. The CSS retrieves certificate status from the status reporting 
component using the identified certificate status checking method and closes 
communications session. The CSS parses or interprets the retrieved certificate status, 

25 associates a time-to-live value equal to the period specified by status type as stated in 
the CSS policy, and adds at least the certificate's ID, status, and time-to-live values to 
issuing CA's certificate status cache. The CSS then returns certificate status to 
requesting system. 

A method for enrolling users in a system or TCU where certificate are issued by 
30 an approved issuing CA that is known to a CSS includes vetting the user using 

established membership procedures and criteria, entering user enrollment information 
that has also been signed by an approved organization sponsor, and creating and 
sending a certificate request to the identified issuing CA. The user's authentication 
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certificate is retrieved, issued, and placed on a token for delivery. Digital signature, 
digital signature verification and the CSS certificate status check are performed to 
ensure that public-key pair generation and certificate issuance process were completed 
correctly. The user is required to sign the user acceptance agreement that commits the 
5 user to give the same weight to use of their digital signature as they give to use of his or 
its hand written signature, the token is delivered to the user, and the user's system or 
TCU account is activated. 

A method of enrolling users in a system or TCU where the user already has a 
certificate issued by a CA that is not previously known to a CSS can include querying 

10 the user's token for the user's authentication certificate and obtaining issuer 
information, and querying the CSS knowledge base to see if the issuing CA is 
contained therein. If not, the industry or organization policy administrator is contacted 
to determine whether or not the issuing CA meets the system rules for CA inclusion. 
Where the issuing CA is deemed "not authorized", registration terminates, and where 

15 the issuing CA is deemed "authorized", enrollment proceeds as described above. 

A portion of a user's authentication certificate contents may be used to bind the 
certificate to a user's account by, after approving user for access to system or TCU, 
entering user enrollment information, inserting the user's token, that holds their 
authentication certificate, into a local token reader, retrieving and displaying the 

20 certificate contents, having the user affirm that the contents are correct, and adding 
selected fields to the system or TCU user enrollment data that is extracted from the 
certificate, such as certificate ID, issuing CA, a subset of the user's distinguished name 
or other identification information conveyed in certificate extensions (e.g., 
subjectAltName). The extracted data may be specified in the system or TCU policy so 

25 that extraction and data entry may be automated. 

A method whereby a submitter of an information object vouches for the 
authenticity of a submitted information object includes the step of affixing the 
submitter's signature block to an information object and/or wrapper and forwarding it to 
a system or TCU. If signature block validation fails, the TCU requests retransmission or 

30 remedy, and if signature block validation succeeds, the TCU then checks that the 

identity of the submitter matches that of the initiator of communication session, rejecting 
the submission if the initiator and submitter are different. If all checks succeed, the 
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TCU adds its signature block to the submission, creating an electronic original 
information object. 

A method in a CSS of maintaining accurate and timely certificate status for real- 
time certificate status reporting means that employ a time-to-live data element includes 
these steps. If a CRL status method is used, then the CSS reports status. If certificate 
status is in cache and the time-to-live data element is not exceeded, then the CSS 
reports status. If the time-to-live data element is exceeded, the CSS clears the 
certificate status entry from the issuing CA cache. If status is retrieved using a real-time 
certificate status reporting means (e.g., OCSP, LDAP query, etc.) and status is not in 
cache, certificate status is requested, retrieved and reported. The CSS then adds at 
least the certificate's ID, certificate status and time-to-live to its cache and returns 
certificate status to the requesting system or TCU. 

A certificate status use-counter data element may be added to a certificate's 
status entry in the CSS's issuing CA cache, and the status use-counter can be 
incremented or decremented every time a certificate's status is checked. If the status 
use-counter passes a threshold set by CSS policy, then the certificate status may be 
reported, but the CSS then clears the certificate status entry from the issuing CA cache. 
If the CSS-returned certificate status is invalid or revoked, then the system or TCU logs 
and/or reports the error to the submitter and/or transaction owner, and the requested 
action is disallowed and remedy sought. Otherwise, the digital signature is deemed 
valid and the requested action is allowed. A certificate status last-accessed data 
element may be added and used in conjunction with the use-counter to determine the 
activity level of the certificates' status. 

A background process can cause the CSS to automatically retrieve updated 
certificate status and establish new time-to-live and use-counter data elements when a 
criterion in the CSS policy is met. This pre-fetch may be enabled to shorten the 
average time between system or TCU certificate status request and CSS response. 

If a request is made to the CSS to retrieve certificate status for a new certificate 
and the issuing CA cache has reached its allocated buffer size limit, the certificate 
status last-accessed data element may be added to the certificate's status entry in the 
CSS's issuing CA cache. The CSS searches the issuing CA cache for the latest- 
accessed data element for the oldest date (least-frequently-used) and clears that entry. 
The CSS then retrieves the requested certificates status, places it in the freed location 
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in the issuing CA cache and reports the status to the system or TCU which acts 
according to policy. 

A method of status checking in a distributed CSS includes coordinating between 
CSSs whenever a new issuing CA is introduced, establishing entries in all CSS 
knowledge bases if another CSS has primary responsibility for querying an issuing CA, 
querying other CSSs instead of an issuing CA to reduce communications between the 
CSS and issuing CAs, synchronizing and caching certificate statuses locally if multiple 
local systems have a heavy concentration of certificate status requests against an 
issuing CA, and sharing or transferring the querying responsibility if another CSS has 
heavier activity with a given issuing CA than the original primary CSS. 

Excluding a set of users associated with an issuing CA by changing the issuing 
CA reference in a CSS knowledge base to "not approved" can be done by requesting 
that approval for the issuing CA be withdrawn, reviewing the request on merit and 
determining what if any action is needed, and if it is determined that for any reason the 
issuing CA should be disabled, then changing the issuing CA's status in the CSS 
knowledge base to "not approved". Any subsequent request for status of a certificate 
issued by a CA listed as "not approved" results in the CSS returning a failed status. 

A method of re-enabling a set of users disabled by previously setting an issuing 
CA reference to "not approved" can be done by requesting that approval be granted for 
re-enabling the issuing CA, reviewing the request on merit and determining what if any 
action is needed, and if it is determined that the issuing CA should be re-enabled, then 
changing the issuing CA's status in a CSS knowledge base to "approved". The CSS 
processes certificate status requests for reinstated issuing CAs as it would any other 
"approved" CA. 

Communication with status reporting components can be established by creating 
a modular and reusable apparatus for each certificate status protocol used to locate, 
request and retrieve such information, using a version of the apparatus that is 
compatible with all CAs and responders that understand a particular certificate status 
protocol, and having a version of the apparatus for each status reporting protocol that is 
in use. The apparatus is designed so that it is easily adaptable to support future 
certificate status reporting protocols. 

Executing a transaction in which the submitter is a first TCU and the submission 
is to transfer custody of one or more electronic originals to a second TCU can include 
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having the owner of the transaction instruct the first TCU to transfer custody of one or 
more electronic original documents to a second TCU. The owner of the transaction 
instructs the second TCU to transfer custody of one or more electronic original 
documents, and the owner provides the first TCU with a manifest that identifies which 
5 electronic originals are to be transferred to the second TCU. The first TCU establishes 
communications with the second TCU, and identifies the purpose of its actions to the 
second TCU. The first TCU or owner may transmit the manifest to the second TCU so 
that it is able to determine when the transfer of custody has been completed. The first 
TCU transfers each identified electronic original to the second TCU, which uses the 
D CSS to ensure that the first TCU's digital signature on each transferred electronic 
original is valid and that the electronic originals are unaltered. If any of the first TCU's 
digital signatures are invalid, then the second TCU notifies the first TCU and seeks 
remedy (e.g., asks the first TCU to resign using current authentication certificate). If the 
first TCU is unable to comply, the second TCU logs the event and notifies the 
5 transaction owner that the requested transfer of custody has failed; otherwise, the 
second TCU creates a new wrapper for each successfully transferred information 
object, adding a date-time stamp and its signature block. The second TCU notifies the 
first TCU of each successful transfer, and upon completion, the first TCU may at the 
discretion of the owner either mark and retain copies in such a manner that they cannot 
be construed to be an original, or may destroy all copies that exist of the transferred 
information objects. The process is repeated until all identified electronic originals are 
transferred. In this way, the second TCU becomes the custodian for the transferred 
records that are the authoritative copies. The second TCU may append a reliable date 
and time, digitally sign, wrap and store the manifest to make it an independent element 
of the trail-of-custody. 

In executing a transaction, the owner's instruction may also state that a transfer 
of ownership takes place, and transfer of ownership documentation may be placed in 
either the first or second TCU. The responsible TCU validates the authenticity of the 
transfer of ownership documents by verifying all digital signatures, certificate validity 
periods, and using the CSS to check certificate status. The TCU then appends reliable 
date and time, and digitally signs, wraps and stores these now electronic original 
information objects, which are added to the manifest. Where these electronic originals 
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are placed in the first TCU, transfer-of-ownership is implemented prior to transfer-of- 
custody, and the initiating manifest becomes part of the trail-of-ownership. 

Some of the transferred records may be simple electronic information objects 
and not just electronic originals. The CSS may use any appropriate certificate status 
protocol to communicate with a system or TCU. 

This invention can be embodied in many different forms without departing from 
its essential character, and thus the embodiments described above should be 
considered illustrative, not restrictive, in all respects. It is emphasized that the terms 
"comprises" and "comprising", as used in this description and the following claims, are 
meant as specifying the presence of stated features without precluding the presence of 
one or more other features. The intended scope of the invention is set forth by the 
following claims, rather than the preceding description, and all variations that fall within 
the scope of the claims are intended to be embraced therein. 
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